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1.  Introduction 


The  U.S.  Army  Research  Laboratory  (ARL)  participated  in  the  command,  control, 
communications,  computers,  intelligence,  surveillance  and  reconnaissance  (C4ISR)  On-the- 
Move  (OTM)  experiment  that  was  held  at  Fort  Dix,  New  Jersey,  during  the  summer  of  2006. 

The  experiment  was  hosted  by  the  Communications  and  Electronics  Research  Development 
Engineering  Center  (CERDEC)  Special  Projects  Office  (SPO)  C4ISR  Integration  Test  bed.  Port 
Monmouth,  New  Jersey. 

The  C4ISR  OTM  experiment  was  designed  to  examine  the  effect  that  advanced  C4ISR 
technologies  have  on  situational  awareness  (SA)  of  an  Army  Puture  Combat  Systems  (PCS)- 
based  infantry  company  and  reconnaissance  troop.  The  experiment  included  live  Soldier 
exercises,  with  each  Soldier  being  connected  to  a  battlefield  tactical  network.  Also  connected  to 
the  tactical  network  was  a  suite  of  manned  and  unmanned  sensor  assets  controlled  via  a  cohesive 
command  and  control  environment'. 

ARE’s  objective  in  the  exercise  was  to  demonstrate  system-level  integration  of  developing 
technologies  for  small  unit  combat  operations  aimed  at  improving  SA.  ARL  brought  expertise  in 
unattended  ground  sensing  technology,  wireless  mobile  ad  hoc  communication,  and  information 
fusion  to  the  experiment.  The  ARL  C4ISR  system  included  multimodal  unattended  ground 
sensors,  trip  wire  imagers,  multiple  human-portable  robotic  vehicles  (PackBots),  and  an 
unmanned  scout/light  cargo  carrying  robotic  vehicle  (R-Gator).  These  disparate  technologies 
were  integrated  into  an  overall  C4ISR  system  with  the  use  of  a  combination  of  proprietary  and 
commercial  off-the-shelf  (COTS)  components,  and  they  communicated  wirelessly  via  various 
methods.  Users  can  control  the  system  in  a  number  of  ways,  including  using  a  remote  mobile 
platform  mounted  in  a  tactical  high  mobility  multipurpose  wheeled  vehicle  (HMMWV)  or  via  an 
operator  control  unit  (OCU)  carried  by  a  dismounted  Soldier.  In  addition,  the  ARL  C4ISR 
system  was  integrated  into  the  Porce  XXI  Battle  Command,  Brigade  and  Below  (PBCB2) 
display  suite,  which  provided  users  with  the  capability  of  controlling  and  accessing  data  from 
multiple  systems  at  a  central  location. 


2.  ARL  Involvement 


Pour  of  the  six  technology  directorates  at  ARL  participated  in  the  C4ISR  OTM  experiment.  The 
Weapons  and  Materials  Research  Directorate  (WMRD)  provided  a  number  of  unmanned  aerial 
vehicle  (UAV)  technologies,  the  Human  Research  and  Engineering  Directorate  (HRED) 

'C4ISR  OTM  Program  Overview,  www.c4isrotm.net  (cached  page  only). 
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provided  operational  and  usability  assessments,  the  Sensors  and  Electron  Devices  Directorate 
(SEDD)  provided  multimodal  unattended  ground  sensors  (EIGS),  and  the  Computational  and 
Information  Sciences  Directorate  (CISD)  provided  unmanned  ground  vehicle  (UGV) 
technologies  and  integration  software.  This  report  focuses  on  the  work  that  CISD  performed  for 
the  experiment. 

HRED  played  a  significant  role  in  gathering  useful  feedback  from  the  Soldier  end  users  of  the 
unmanned  systems  brought  by  CISD  and  SEDD.  By  administering  surveys  to  the  dismounted 
Soldiers  during  the  exercises,  HRED  personnel  were  able  to  gain  insight  into  whether  the  new 
technologies  improved  Soldiers’  perceived  SA,  to  gain  immediate  feedback  about  how  the 
Soldiers  were  using  ARE  technologies,  and  to  document  any  issues  that  arose  during  their  use  in 
the  field. 

CISD  and  SEDD  collaborated  on  integration  efforts  in  preparation  for  the  experiment.  SEDD 
contributed  a  suite  of  UGSs  to  the  experiment  and  wanted  to  integrate  into  CISD’s  command  and 
control  software  so  that  sensor  data  could  be  displayed  on  a  mapping  system.  Working  closely 
with  CERDEC,  the  two  directorates  integrated  communications  from  the  sensors  to  platoon-level 
vehicles  using  CISD’s  Blue  Radio,  a  low  power  and  low  data  rate  radio  designed  for  sensor 
networking.  Eurther,  data  provided  by  the  UGSs  was  integrated  into  two  pieces  of  CISD 
software.  Sensed  Object  Server  (SOS)  and  Tactical  Object  Server  (TOS).  These  applications  ran 
on  a  server  in  the  platoon-level  vehicle.  SOS  converted  low-level  data  from  sensors  into  a  more 
usable  format,  which  TOS  then  converted  into  tactical  symbols  that  could  be  displayed  on 
EBCB2,  the  mapping  system  used  at  C4ISR  OTM,  via  a  CERDEC  message  translator  called  the 
Conduit  Gateway.  These  integration  efforts  allowed  sensor  data  to  appear  as  speed,  position,  and 
track  (SPOT)  reports  in  the  same  manner  as  user-generated  reports  from  the  unmanned  assets. 
Because  of  the  high  level  of  collaboration  among  CISD,  SEDD,  and  CERDEC,  this  system  was 
able  to  be  brought  on  line  in  the  field  in  less  than  one  day. 

The  other  pieces  of  technology  that  CISD  brought  to  the  experiment  were  its  unmanned  systems 
and  corresponding  mobile  ad  hoc  network  (MANET).  CISD  brought  two  robotic  platforms  to 
the  experiment.  The  first  was  the  PackBoC  Explorer,  manufactured  by  iRobot,  which  acted  as 
the  ECS  small  unmanned  ground  vehicle  (SUGV)  surrogate.  The  second  platform  was  the 
R-Gator^,  also  manufactured  by  iRobot,  which  acted  as  the  ECS  armed  robotic  vehicle  platform 
in  its  reconnaissance,  surveillance,  and  target  acquisition  (ARV-RSTA)  configuration.  CISD 
removed  all  iRobot  proprietary  application  software  from  both  platforms,  choosing  instead  to 
write  its  own  robotic  control  and  network  architecture  software,  giving  it  a  more  robust  feature 
set  while  maintaining  its  openness  and  extensibility.  Connecting  each  robot  to  its  OCU  as  well 
as  to  other  robots  was  a  MANET  built  from  COTS  components  that  had  been  altered  by  CISD  to 
operate  a  modified  version  of  open-source  MANET  software.  The  MANET  features  allowed  the 
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network  operational  range  to  be  extended  by  the  emplaeement  of  CISD  designed  ad  hoe  drop-off 
nodes  along  a  ehosen  path,  thus  giving  the  network  traffie  the  ability  to  “hop”  from  one  node  to 
the  next,  even  on  non-line-of-sight  (NLOS)  paths. 

This  report  focuses  on  the  design,  implementation,  and  results  of  the  MANET  that  was 
implemented  for  robotic  control  in  the  C4ISR  OTM  experiment.  We  discuss  the  research 
relating  to  MANET  design  and  the  low-cost  COTS  equipment  used  to  implement  the  design. 
Further,  discussion  focuses  on  the  drop-off  nodes,  highlighting  their  low  cost  and  ability  to 
extend  the  MANET.  Finally,  we  discuss  the  results  of  numerous  field  experiments  and 
evaluations  performed  in  preparation  for  and  during  the  C4ISR  OTM  experiment. 


3.  Mobile  Ad  Hoc  Networks 


A  MANET  is  generally  defined  as  a  wireless,  self-configuring  ad  hoc  network  that  consists  of 
mobile  nodes  connected  together  by  wireless  links.  These  mobile  nodes  can  act  as  routers  to 
forward  routing  information  and  data  to  each  other,  maintaining  network  connectivity  among 
them.  By  exchanging  routing  information  between  nodes,  these  routers  can  freely  move  and 
organize  themselves  into  a  self-configuring  network  of  random  shapes  or  topologies. 

Because  of  its  versatility,  a  MANET  is  a  very  useful  tool  for  meeting  Army  battlefield 
communication  requirements.  The  mobility  provided  by  a  MANET  is  not  only  a  key  factor  for 
survivability  on  the  battlefield  but  also  provides  convenience  and  flexibility  in  executing  the 
Army  mission.  The  ad  hoc  capabilities  allow  the  Army  to  deploy  and  use  network 
communications  without  a  fixed  infrastructure.  The  MANET  can  be  quickly  deployed  in  urban 
environments  or  on  battlefields  where  network  infrastructure  can  be  destroyed,  unreliable,  or 
unavailable.  The  self-configuration  capability  of  a  MANET  allows  mobile  Army  units  be  very 
adaptive  to  topological  changes  without  manual  reconfiguration  of  the  network. 

ARE  has  researched  MANETs  and  their  application  for  military  uses.  Several  self-configuration 
protocols  are  used  for  implementing  a  MANET,  but  there  are  two  main  MANET  protocol 
groups:  proactive  and  reactive.  In  reactive  MANET  protocols  (RMPs),  routing  information 
between  nodes  is  determined  when  communications  are  needed.  Thus,  communication  overhead 
is  less  but  network  communication  latency  is  high.  Conversely,  in  proactive  MANET  protocols 
(PMPs),  routing  information  of  nodes  is  constantly  exchanged  on  the  network,  yielding  high 
network  overhead  but  low  network  latency.  An  open  source  version  of  a  proactive  MANET 
protocol  is  called  Optimized  Link  State  Routing  Daemon  (OLSRD)"^.  OLSRD  is  an 
implementation  of  the  Optimized  Link  State  Routing  (OLSR)  protocol. 


^Developed  by  Andreas  T0miesen  and  Thomas  Lopatic  (www.olsr.org). 
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Typically,  MANET  nodes  have  the  capability  to  communicate  with  each  other  but  do  not  have 
any  speeialized  processing  capabilities  to  perform  dedicated  tasks  such  as  computation,  video  or 
fde  serving.  Dedicated  computer  nodes  for  specific  tasks  must  be  equipped  with  both  a  wireless 
local  area  network  (LAN)  interface  and  the  MANET  protoeol  in  order  to  eommunicate  in  the 
MANET  environment.  These  requirements  will  make  dedicated  computer  nodes  less  mobile 
since  they  will  be  larger  and  heavier  and  will  consume  more  power.  “MANETized”  computer 
nodes  are  not  readily  available  as  already  defined  COTS  produets  since  there  is  limited  demand 
for  MANET  capabilities  outside  military  applications,  and  no  actual  MANET  protocol  standards 
have  been  established.  The  solution  is  to  develop  and  implement  gateway  capabilities  from 
regular  computer  networks  such  as  Ethernet  to  MANET  and  viee  versa.  With  this 
implementation,  the  MANET  nodes  eommunicate  with  one  another  while  the  dedicated 
computer  nodes  are  eonneeted  to  the  MANET  nodes  through  a  regular  network  interface.  This 
teehnique  is  called  the  sub-network  gateway  to  MANET  teehnique. 

For  implementation  of  a  MANET,  ARE  has  employed  the  ad  hoe  eapability  of  wireless  LANs 
such  as  Institute  of  Electrical  and  Electronics  Engineering  (IEEE)  802.1  la/b/g  as  a  means  to 
aehieve  mobility.  The  IEEE  802. 1  Ig  wireless  standard  is  the  best  choice  since  it  provides  faster 
data  rates  (54  Mbps  maximum)  and  farther  wireless  operational  distanee  than  the  IEEE  802.1  la 
or  IEEE  802.1  Ib  protoeols. 

In  2004,  for  the  Department  of  Defense  (DoD)  Horizontal  Fusion  program,  ARE  developed 
MANET  nodes  ealled  black  ad  hoc  nodes  with  the  support  of  BBN  Teehnologies  and  Teleeordia, 
Inc.  The  MANET  protoeol  used  for  the  black  ad  hoc  node  was  Hazy  Sighted  Link  State  (HSLS), 
whieh  was  developed  and  lieensed  by  BBN  Technologies.  Sinee  the  black  ad  hoc  nodes  were 
designed  specifically  for  the  Horizontal  Fusion  program  and  were  the  first  experimental 
MANET,  they  were  limited  in  capability  and  performance. 

In  2006,  with  the  maturity  and  proliferation  of  wireless  LANs,  ARE  developed  new  MANET 
nodes,  called  blue  ad  hoe  nodes,  which  have  a  smaller  form  factor  and  better  performance.  As  a 
cost-saving  measure,  the  blue  ad  hoe  nodes  were  built  with  Linksys  wireless  LAN  routers  and 
the  open  source  OLSRD.  The  Linksys  router  is  built  with  an  internal  100-mW  amplifier  for 
802.1  Ig  wireless  LAN  protoeol  which  allows  for  long  distance  wireless  operation  (as  far  as 
500  m)  without  the  use  of  high-gain  antennae.  It  is  also  equipped  with  two  wired  Ethernet 
10/100  interfaces  to  allow  implementation  of  the  sub-network  gateway  to  MANET  teehnique  for 
conneeting  dedicated  eomputer  nodes.  With  the  sub-network  gateway  technique,  the  sub¬ 
network  (subnet)  attached  to  a  MANET  node  is  advertised  in  the  MANET  environment  so  that 
the  gateway  to  this  subnet  is  through  its  MANET  node.  Figure  1  depicts  a  MANET  topology 
with  subnets  attaehed  to  some  MANET  nodes. 
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Figure  1 .  Representation  of  a  MANET  topology  with  subnets  attached  to  some  MANET  nodes. 

Examples  of  subnets  used  by  ARE  are  robotie  platforms,  robotie  OCEls,  and  mobile  video 
servers.  By  eonneeting  to  a  MANET  node,  the  robotie  OCEl  ean  maneuver  a  remote  robot 
eonneeted  to  another  MANET  node.  Similarly,  mobile  video  servers  attaehed  to  a  MANET  node 
ean  provide  streaming  video  to  any  non-MANET  nodes  on  subnets  that  are  eonneeted  to 
MANET  nodes. 

Intermediate  MANET  nodes  forward  network  information  and  data  of  other  MANET  nodes. 
Thus,  MANET  nodes  ean  be  used  to  extend  the  operative  range  of  linked  nodes  by  hopping 
between  MANET  nodes.  These  intermediate  nodes  do  not  have  to  be  eonneeted  to  any  subnets 
and  are  ealled  drop-off  nodes. 

To  minimize  eost  and  developed  time,  the  Battlefield  Communieation  Network  Braneh  (CI-CN) 
of  ARL’s  CISD  developed  ad  hoe  nodes  using  Einksys  wireless  LAN  routers  (models 
WRT54GS  and  WRTSL54GS)  and  open  souree  software  (OpenWRT^,  OLSRD  and  OpenVPN^). 
The  network  faeility  of  the  Einksys  WRTSL54GS  eonsists  of  two  wired  10/100  Ethernet 
interfaees  and  one  wireless  LAN  interfaee  (eapable  of  IEEE  802.1  Ib/g).  OpenWRT  is  a  version 
of  the  Linux  operating  system  with  a  small  footprint  speoifieally  designed  for  embedded  deviees. 
Two  other  important  software  eomponents  used  in  the  ad  hoe  nodes  for  the  C4ISR  OTM 
experiment  were  OLSRD,  an  open-souree  proaetive  MANET  routing  software,  and  Open  VPN, 
an  open-souree  virtual  private  network  (VPN)  software  used  for  seeurity  and  eneryption. 


^OpenWRT  was  developed  by  Mike  Baker  (openwrt.org). 
^OpenVPN  is  a  trademark  of  Open  VPN  Solutions  LLC. 
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Secure  communications  in  the  MANET  are  achieved  with  encryption  provided  by  Wired 
Equivalent  Privacy  (WEP)  and  Open  VPN.  The  WEP  protocol,  which  is  part  of  the  IEEE  802. 1 1 
wireless  networking  standard,  encrypts  network  frames  before  transmitting  to  the  air  medium. 

The  WEP  encryption  provides  confidential  communication  at  the  physical  and  data  link  layer, 
known  as  layers  1  and  2,  respectively,  in  the  Open  System  Interconnection  (OSI)  model  of 
communication  network.  For  strong  encryption,  a  128-bit-key  encryption  is  used  for  the  WEP  of 
blue  ad  hoc  nodes.  Although  there  are  security  limitations  of  WEP  when  one  is  using  short 
encryption  keys  (40  or  64  bits),  WEP  encryption  is  good  enough  to  provide  protection  for 
MANET  routing  information,  which  is  usually  not  as  protected  as  internet  routing  information. 

The  main  function  of  Open  VPN  is  to  provide  secure  communication  of  private  networks  over 
unsecured  public  networks  such  as  the  internet.  To  achieve  secure  communication,  OpenVPN 
creates  cryptographic  tunnels  through  public  networks  to  link  private  networks  together.  For 
application  in  a  MANET,  OpenVPN  is  used  to  create  VPN  tunnels  to  securely  link  subnets, 
which  are  attached  to  MANET  nodes.  OpenVPN  provides  communication  encryption  at  the 
network  layer  (layer  3  of  the  OSI  model),  establishing  an  end-to-end  communication  encryption 
between  two  MANET  nodes.  With  cryptographic  tunneling  protocols,  OpenVPN  enables 
confidentiality  (privacy),  authentication  (sender  and  receiver  identity),  and  integrity  (unaltered 
data)  for  communications  in  a  MANET.  Figure  2  illustrates  a  VPN  tunnel  connecting  subnets  si 
to  subnet  s6. 


Figure  2.  A  VPN  tunnel  connecting  subnets  si  and  s6. 
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4.  Design  and  Implementation 


4.1  Linksys  Router  Software  Installation  and  Configuration 

Before  ad  hoe  eommunication  payloads  were  designed  to  provide  network  eonneetivity  to  all  the 
system  assets  in  the  MANET,  eonfiguration  of  the  COTS  wireless  routers  had  to  be  performed. 
For  eaeh  of  the  nodes,  eonfiguration  began  with  a  new,  unmodified  Linksys  wireless  LAN 
router. 

The  first  step  of  the  eonfiguration  proeess  was  to  replaee  the  proprietary  firmware  with  open- 
souree  software  that  eontained  all  the  software  eomponents  needed  for  the  MANET,  namely, 
OpenWRT,  OLSRD,  and  Open  VPN.  This  .bin  file  was  flashed  onto  the  router  via  the  web- 
browser-based  interfaee  and  was  rebooted. 

Following  the  firmware  installation,  a  telnet  eonneetion  to  the  router  via  the  default  internet 
protoeol  (IP)  address^  was  established.  A  manual  reboot  was  then  performed  to  allow 
OpenWRT  to  eomplete  initialization  of  the  new  Linux  file  system. 

The  telnet  eonneetion  was  then  re-established,  and  a  password  was  set  on  the  router  to  prevent 
unauthorized  aeeess.  A  set-up  seript  file  and  tar  fdes  needed  by  the  seript  were  seeurely  eopied 
to  the  /tmp  direetory.  The  set-up  tar  file  was  extraeted  into  the  /tmp  folder,  and  then  the  set-up 
seript  was  exeeuted.  The  node  host  name  and  IP  address  were  set  as  desired  when  prompted  by 
the  seript,  with  a  192. 168.x.  1  format.  The  settings  were  saved  to  memory  with  the  nvram 
eommand,  and  the  router  was  rebooted  to  finish  IP  eonfiguration. 

The  last  step  was  to  eonfigure  the  VPN.  We  aeeomplished  this  by  running  a  vpn  eonfiguration 
seript,  whieh  prompted  for  the  two  IP  addresses  in  the  VPN  pair,  for  example,  192.168.125.1  and 
192.168.135.1.  These  two  addresses  would  eorrespond  to  a  robot-OCU  pair.  The  seript  then 
produeed  a  eonfiguration  file  for  the  VPN,  whieh  was  virtually  linked  in  the  OS  to  point  at  the 
vpn.eonf  file.  After  a  final  reboot,  router  eonfiguration  was  eompleted. 

4.2  PackBot  Payload  Design 

In  order  to  test  the  funetionality  of  the  MANET,  several  different  platforms  required  ad  hoe 
nodes  to  be  developed,  ineluding  two  robotie  platforms.  The  first  robotie  platform  diseussed  is 
the  IRobot  PaekBot  Explorer. 

The  PaekBot  Explorer  standard  eommunieations  protoeol  is  the  IEEE  802.1  Ig  wireless  standard. 
The  platform  is  designed  with  a  payload  bay  so  that  modular  payloads  ean  be  easily  integrated 
onto  the  robot.  The  payload  interfaees  to  the  robot  through  a  proprietary  45-pin  eonneetor.  This 
eonneetor  allows  the  payload  to  eommunieate  with  the  robot  eomputer  through  a  variety  of 


’The  default  IP  address  of  the  WRTSL54GS  is  192.168.1.1 
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interfaces,  including  universal  serial  bus  (USB)  and  Ethernet,  and  to  draw  24-V  DC  power  from 
the  robot. 


In  order  to  provide  a  weather-resistant  payload,  the  COTS-based  system  had  to  be  packaged. 
Because  of  time  constraints,  PackBot  payload  containers  made  from  rapid  prototyping  plastic 
were  used.  Although  the  container  was  weatherized,  the  lightweight  plastic  was  not  ideal  for  a 
ruggedized  system.  However,  since  the  payload  bay  sits  within  the  frame  of  the  robot,  the 
payload  receives  a  fair  amount  of  protection  from  the  robotic  platform  itself. 


Figure  3.  PackBots  showing  ARL  ad  hoc  payloads. 

In  this  design,  the  reconfigured  Linksys  router  was  removed  from  its  plastic  case  and  the  antenna 
was  removed.  This  was  done  so  that  the  router  could  be  repackaged  into  the  payload  sized 
container.  Standoffs  were  used  to  mount  the  router  board  to  the  bottom  of  the  payload  container, 
to  prevent  the  electronics  from  being  jostled  while  the  robot  was  in  motion,  and  to  position  it 
above  the  bottom  of  the  payload  if  moisture  entered  the  container. 

The  Linksys  router  required  12-V  DC  power,  but  the  power  provided  by  the  robot  is  24-V  DC; 
therefore,  the  payload  required  the  addition  of  a  24- 12-V  DC-DC  converter.  A  PC- 104  style 
DC-DC  voltage  converter  was  selected  to  accomplish  this  because  of  its  small  form  factor.  The 
voltage  converter  was  mounted  into  the  payload  container  below  the  footprint  of  the  router 
board. 
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An  antenna  mount  was  then  placed  on  the  outside  of  the  payload  package  to  replace  the  standard 
router  antenna,  which  had  been  removed  to  facilitate  packaging.  To  minimize  the  loss  of  gain, 
the  new  antenna  cable  was  soldered  directly  to  the  router  board  on  one  end  and  connected  to  the 
antenna  via  a  single  radio  frequency  (RF)  connector  on  the  other  end.  This  design  eliminated  the 
need  for  multiple  gain-reducing  RF  connectors  between  the  board  and  the  antenna.  A  high  gain, 
flexible  antenna  originally  in  use  on  the  PackBot  was  selected  for  the  payload.  This  was  to 
accommodate  the  operational  capabilities  of  the  PackBot,  which  include  the  ability  to  drive  while 
inverted. 

Once  all  the  payload  components  were  designed  and  constructed,  the  payload  hardware  was 
integrated  with  the  robot.  A  small  integrated  circuit  board  that  provided  24-V  DC  power  and 
Ethernet  interfaces  with  the  proprietary  connector  was  added  to  the  payload.  Power  was  routed 
to  the  voltage  converter  and  then  connected  to  the  router  with  a  custom  connector  plugged  into 
the  existing  DC  power  receptacle.  Signal  was  sent  directly  between  the  Ethernet  port  on  the 
breakout  board  and  the  Ethernet  interface  on  the  router  via  a  standard  Cat.5  cable.  The  final  step 
was  to  re-configure  the  software  and  IP  address  of  the  PackBot  so  that  it  used  the  new  ad  hoc 
payload  as  its  gateway. 

4,3  Gator  Payload  Design 

The  second  robotic  platform  that  was  modified  was  an  IRobot/John  Deere  R-Gator.  The  R-Gator 
is  a  larger  platform  developed  for  transport  and  RSTA  purposes.  It  is  capable  of  being  driven 
manually,  tele-operated,  or  with  semi-autonomous  techniques  such  as  waypoint  following.  The 
platform  is  multi-functional  and  can  be  used  to  transport  people,  supplies,  or  smaller  robotic 
assets  such  as  the  PackBot  Explorer. 

The  R-Gator  is  designed  with  a  large  payload  container  that  separates  the  passenger  seats  and 
cargo  area  in  the  rear  of  the  robot.  This  container  is  used  to  house  the  electronics  necessary  to 
control  the  platform  as  a  robotic  asset.  Since  there  was  available  space  in  this  container,  the 
COTS  ad  hoc  node  did  not  need  to  be  housed  in  a  separate  weather-resistant  and  ruggedized 
housing.  Instead,  the  router  could  be  placed  in  the  available  free  space. 

The  R-Gator  is  equipped  with  two  antennas,  so  a  slightly  different  Einksys  router  (Model 
WRT54GS)  was  used.  The  selected  router  had  two  antenna  input,  making  it  capable  of  taking 
advantage  of  antenna  diversity.  Antenna  diversity  uses  multiple  antennas  to  use  multi-path 
environments,  thus  improving  performance  and  providing  greater  signal  range. 

The  robot  had  two  available  power  points  in  the  payload,  one  operating  at  36-V  DC  unregulated 
and  the  second  operating  at  24-V  DC  regulated.  However,  like  the  previously  integrated  version 
of  the  Einksys  router,  this  version  also  required  an  input  of  12-V  DC.  To  provide  this,  the  24-V 
DC  power  point  was  used,  and  a  simple  24- 12-V  DC-DC  converter  was  installed.  Since  the 
regulated  24-V  line  was  not  completely  immune  to  slight  variations  in  voltage  level  as  other 
components  in  the  robot  were  switched  off  and  on,  and  the  tolerance  to  power  variations  of  the 
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router  board  was  unknown,  the  necessary  resistors  and  capacitors  were  soldered  onto  the  power 
converter  to  ensure  a  stable  12-V  DC  output. 

Once  the  ad  hoc  node  was  powered,  the  signal  needed  to  be  connected  to  the  computer  systems. 
Unlike  the  PackBot,  which  has  a  single  central  processing  unit,  the  R-Gator  contains  two 
computer  systems.  One  handles  robotic  control,  while  the  other  handles  image  processing  and 
geo-location  via  a  compass  and  GPS  unit.  Each  was  connected  into  the  router  via  an  Ethernet 
connection  and  was  given  a  unique  IP  address  in  the  appropriate  IP  range  in  order  for  the  router 
to  serve  as  the  gateway  for  both  machines. 

4,4  Drop-off  Node  Design 

Preliminary  testing  indicated  that  the  communications  range  of  an  ad  hoc  node  was 
approximately  0.2  mile.  In  order  to  extend  the  range  of  the  communications  network  to  a 
suitable  distance  for  field  operations,  as  well  as  to  allow  assets  to  be  controlled  in  NLOS 
situations,  drop-off  ad  hoc  nodes  were  added  to  the  system.  These  nodes  were  needed  to  act  as 
repeaters  that  could  pass  communications  between  multiple  robot-OCU  pairs.  They  needed  to  be 
capable  of  running  for  long  periods  of  time  without  an  external  power  source  and  be  easily 
transportable  so  that  they  could  quickly  be  emplaced  and  rearranged  in  the  field  as  the  conditions 
of  the  battlefield  environment  dictated. 

To  solve  the  power  problem,  a  12-V  DC  battery  pack,  which  is  intended  for  use  in  portable  DVD 
player  applications,  was  chosen  as  a  power  source.  The  battery  was  lightweight  and  had  a  small 
form  factor.  Testing  of  the  battery  pack  determined  that  it  could  provide  power  to  an  ad  hoc 
node  for  as  many  as  12  hours,  well  beyond  the  power  requirements  of  the  drop-off  node. 

To  provide  a  fieldable  drop-off  node  solution,  the  system  had  to  be  weather  resistant  and  easily 
transportable.  We  accomplished  this  by  packaging  the  node  components  in  a  small  (10  x  8  x 
5  inches)  Pelican  case.  The  router  board  was  secured  to  the  bottom  of  the  Pelican  case  with 
standoffs  to  prevent  it  from  being  damaged  during  transport.  The  battery  was  secured  to  the 
bottom  of  the  case  with  industrial  strength  Velcro^  so  that  it  could  be  held  in  place  but  could  also 
be  easily  removed  and  replaced  as  needed.  An  AC  adaptor  was  needed  to  charge  the  battery 
when  the  system  was  not  fielded,  and  it  was  desired  that  the  antenna  be  removable  to  limit 
potential  damage  during  transport.  Thus,  the  cases  were  designed  to  allow  for  enough  space  to 
store  the  AC  adaptor  and  antenna  so  that  a  single  drop-off  node  unit  was  completely  self- 
sustaining. 

The  stock  Einksys  router  antenna  was  removed  from  the  router  unit  so  that  it  could  be  mounted 
inside  the  Pelican  case.  This  was  done  to  create  a  weather-resistant  system  and  so  that  a  7-dB 
gain  antenna  could  be  added  to  the  system.  The  higher  gain  antenna  was  chosen  to  increase  the 
effective  range  of  an  individual  node.  In  order  to  limit  the  loss  between  the  antenna  and  the 


^Velcro  is  a  registered  trademark  of  Velcro  USA,  Inc. 
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board,  care  was  taken  to  limit  the  number  of  conneetors  used,  while  the  length  of  the  antenna 
wire  was  kept  to  a  minimum.  Simultaneously,  the  design  requirements  necessitated  that  the  wire 
be  long  enough  to  help  the  lid  of  the  ease  to  open  easily  so  the  system  eould  be  assembled  and 
disassembled.  A  hole  was  drilled  through  the  plastie  router  ease  lid  so  that  no  strain  would  be 
placed  on  the  solder  joint  if  the  wire  were  pulled  when  the  case  was  opened  or  closed.  The  RF 
conneetor  selected  was  a  reverse  polarity  TNC  female  connector,  which  mated  with  the  chosen 
antenna.  The  need  for  this  non-standard  connector  required  that  the  wiring  assembly  be 
fabricated  in  house,  instead  of  being  purehased  from  a  commercial  site. 


Figure  4.  Internals  of  ARL  ad  hoc  drop-off  node. 

Since  the  design  of  the  drop-off  module  required  the  system  to  be  easily  transportable,  it  had  an 
inherently  small  form  faetor.  This  was  problematie  since  the  eloser  the  antenna  is  to  the  ground, 
the  smaller  the  range  of  the  node.  During  field  testing,  it  was  determined  that  the  nodes  could  be 
strategieally  placed  in  trees,  just  above  eye  level.  This  placement  was  optimal  for  several 
reasons.  The  elevation  gain  allowed  the  nodes  to  operate  above  the  dense  scrub  oak  canopy  in 
the  test  environment  but  below  the  tree  canopy,  giving  us  greater  range  and  improved 
performance.  Further,  because  the  nodes  were  placed  slightly  above  eye  level,  they  were  also 
more  difficult  to  detect  by  the  opposition  foree  as  they  passed  through  the  theater  of  operations. 
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4.5  OCU  Node  Design 


In  order  to  control  the  robotic  assets  described,  an  OCU  had  to  be  designed  and  developed.  The 
OCU  had  to  be  lightweight,  easy  to  carry,  and  ruggedized  to  protect  it  from  the  abuses  of 
dismounted  field  operations.  To  accomplish  this,  a  ruggedized  tablet  PC  was  selected  to  provide 
processing  capabilities.  The  tablet  was  mounted  onto  a  custom  designed  metal  frame  that  housed 
two  joysticks  for  robotic  control.  The  joysticks  were  connected  to  the  tablet  through  the  USB 
port.  A  neck  strap  was  connected  to  the  frame  to  make  the  unit  easier  to  carry.  The  router  was 
mounted  to  the  back  of  the  frame  so  that  everything  was  connected  as  a  stand-alone  system. 

The  OCU  needed  to  be  able  to  talk  on  two  different  networks  in  order  to  accomplish  its  two 
primary  functions: 

•  Command  and  control  of  a  designated  robotic  asset; 

•  Communication  “uplink”  to  higher  echelons  in  order  to  forward  SA  media  (video  and 
images)  being  collected  by  the  robotic  platform. 

This  need  for  simultaneous  communications  on  two  networks  required  the  system  to  have  two 
network  interface  cards  (NICs).  The  tablet  PC  selected  in  the  design  phase  for  this  project  only 
had  one  on-board  NIC,  so  a  second  was  added  to  the  system  with  the  use  of  a  PCMCIA^  card. 
The  internal  routing  table  on  the  tablet  PC  was  configured  to  ensure  that  traffic  destined  for  the 
robotic  platform  always  passed  through  the  PCMCIA  card,  which  was  connected  to  the  ad  hoc 
router.  All  other  network  traffic  was  routed  through  the  native  NIC,  which  was  connected  to  a 
Soldier  Radio  Waveform  (SRW)  radio  that  passed  data  to  platoon-level  vehicles  for 
dissemination  to  ground  forces.  This  allowed  both  devices  to  communicate  with  their  respective 
networks  without  interfering  with  one  another. 

Since  the  router  was  mounted  onto  the  frame  of  the  OCU,  power  could  be  provided  from  the 
battery  source  providing  power  to  the  tablet.  The  tablet  required  an  input  of  20-V  DC,  while  the 
router  only  needed  12-V  DC,  but  a  battery  cable  was  designed  to  provide  both  of  the  necessary 
voltages  to  the  devices.  After  testing,  it  was  determined  that  the  cable  design  was  correctly 
providing  the  required  voltages,  but  the  requirements  were  causing  the  battery  to  be  drained 
unevenly.  Therefore,  an  independent  battery  for  the  router  was  added  to  the  system,  increasing 
router  run  time  but  increasing  the  weight  of  the  system  3.15  lb  to  14.05  lb. 


Q 

PCMCIA  is  personal  computer  memory  card  international  association  (now  called  PC  cards). 
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Seven  evaluations  of  the  mobile  ad  hoe  system  were  performed  over  a  4-month  period  from  May 
until  August  in  the  summer  of  2006.  The  purpose  of  the  evaluations  was  to  obtain  some  absolute 
performanee  metries  (maximum  range,  allowable  video  rate)  as  well  as  more  qualitative  metries 
relating  to  the  system’s  ability  in  various  environments  and  suitability  for  eertain  types  of 
operations. 

Although  the  final  experiment  took  plaee  at  Fort  Dix,  not  all  the  evaluations  were  performed  on 
site.  Equipment  was  shipped  to  Fort  Dix  inerementally  throughout  the  summer  as  it  beeame 
ready  for  use.  Consequently,  engineers  only  spent  a  week  or  two  at  a  time  on  site  with  the 
equipment,  whieh  mandated  further  testing  and  development  at  Adelphi  Laboratory  Center 
(ALC).  Thus,  improvements  were  often  made  in  equipment  before  shipping  as  a  result  of  the 
evaluations  at  Fort  Dix. 

For  the  C4ISR  OTM  experiment,  the  MANET  was  designed  to  provide  a  robust  and  extendable 
ad  hoe  network.  Its  primary  applieation  was  to  provide  for  tele-operation  of  the  CISD  robotie 
assets.  This  mode  of  operation  allows  the  user  to  remotely  eontrol  the  robotie  platform  using 
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only  streaming  video  displayed  on  the  OCU.  It  had  been  previously  determined  that  the 
minimum  frame  rate  required  to  support  tele-operation  was  approximately  seven  frames  per 
seeond'®.  Thus,  one  of  the  quantitative  measurements  was  the  video  frame  rate  that  the  network 
could  support  in  various  conditions.  The  streaming  video  from  the  cameras  on  the  robotic 
platforms  was  compressed  before  transmission  with  the  Motion- JPEG  compression  scheme.  The 
CISD-designed  underlying  network  architecture,  known  as  CIPNet'^,  breaks  the  stream  into 
packets  to  be  sent  over  the  wireless  network.  On  the  OCU  side,  the  video  stream  is  displayed  by 
CISD’s  command  and  control  application,  CollectControl.  This  Windows'^-based  application 
allows  the  user  to  select  which  asset  s/he  would  like  to  view  and/or  control  and  to  control  the 
resolution  of  the  video  source  and  its  frame  rate. 


Figure  6.  ARL  OCU  showing  operation  of  CollectControl. 

For  the  exercise,  a  VPN  was  established  between  each  robot  and  OCU  pair.  This  was  requested 
by  the  C4ISR  OTM  architects  and  limited  the  actual  ad  hoc  operation  of  the  network.  However, 
this  VPN  did  not  affect  the  ability  of  network  traffic  to  hop  between  end  nodes  via  the  drop-off 
nodes.  It  was  designed  so  that  all  robot-OCU  pairs  could  use  any  given  drop-off  nodes  as 


^^French  et  at,  “Modes  of  Control  of  an  Unmanned  Ground  Vehicle  (UGV)”,  presented  at  the  ARL  Collaborative 
Technology  Alliance  (CTA)  Symposium  as  part  of  the  Advanced  Decision  Architectures  (ADA)  CTA,  2003. 

''choy,  S.  “CIP  Network  Agent  Service  API  User’s  Guide”  ARL,  Adelphi,  MD,  February  2001. 
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Windows  is  a  trademark  of  Microsoft  Corporation. 
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hopping  points,  since  the  drop-off  nodes  were  not  subject  to  the  VPN  limitations.  Instead,  they 
just  passed  all  traffic  and  let  the  end  nodes  do  the  VPN  administration. 

5,1  Initial  Robotic  Field  Test  (Fort  Dix,  New  Jersey) 

Beeause  of  the  short  developmental  schedule,  no  rigorous  testing  had  been  aecomplished  by 
CISD  before  the  delivery  of  the  robotic  systems  on  site  at  Fort  Dix.  They  were  confirmed  to  be 
operational,  but  no  range,  performance,  or  other  tests  were  performed  before  five  systems  were 
shipped. 

System  evaluation  was  performed  on  Range  47  at  Fort  Dix.  The  test  was  performed  on  4  May 
2006  under  sunny  skies.  The  test  site  was  a  large,  mostly  fiat,  reetangular  field  with  a  few 
rolling  hills  and  a  dirt  road  bisecting  its  area  down  the  middle.  There  were  no  trees  in  the  range, 
but  the  range  was  covered  by  areas  of  scrub  brush  and  sand.  Also  present  were  a  number  of 
training  dummies  and  vehicles,  since  the  site  also  served  as  night  vision  training  for  Soldiers 
stationed  at  Fort  Dix. 


11  S:5ilRM 


Figure  7.  Initial  robotic  field  test  site  at  Fort  Dix,  New  Jersey. 

5.1.1  Objectives 

The  objectives  of  this  test  were  straightforward.  First,  we  wanted  to  determine  how  far  our  new 
ad  hoe  communications  network  between  the  OCU  and  robot  could  acceptably  operate  a  robotie 
asset.  Secondly,  we  hoped  to  determine  the  additional  communications  range  that  an  ad  hoe 
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drop-off  node  emplaced  between  the  OCU  and  robot  would  provide,  as  well  as  how  the  network 
performed  when  multiple  drop-off  nodes  were  emplaced.  Finally,  we  wanted  to  determine  the 
effect  the  VPN  had  on  operational  range  and  video  performance. 

5,1,2  Results 

The  distances  listed  in  table  1  reflect  the  point  at  which  driving  the  vehicle  via  the  OCU  video 
became  impossible  because  of  increasingly  erratic  control  capabilities  and  laggy  or  bursty  video. 
In  most  cases,  the  ad  hoc  network  maintained  connection,  but  data  transmission  delays  prevented 
timely  control.  When  used,  the  drop-off  nodes  were  positioned  on  the  ground  on  a  berm 
approximately  0.3  m  above  the  road  level  or  on  cinder  blocks  set  on  the  berm,  approximately 
0.75  m  above  the  road  level. 

Table  1.  Results  of  initial  robotic  field  test. 


Distance  Test 
Performed 

Number  of 
Drop-Off 
Nodes 

Height  of  Drop-Off 
Nodes 

Location  of  Drop- 
Off  Nodes 

VPN 

Result 

OCU  to  PackBot 

0 

N/A 

N/A 

Yes 

193  m 

OCU  to  PackBot 

1 

0.3  m 

160  m 

Yes 

321  m 

OCU  to  PackBot 

1 

0.75  m 

160  m 

Yes 

418  m 

OCU  to  PackBot 

1 

0.75  m 

160  m 

No 

434  m 

OCU  to  PackBot 

2 

0.75  m,  0.3  m 

160  m,  354  m 

Yes 

434  m 

OCU  to  R-Gator 

0 

N/A 

N/A 

Yes 

418  m 

OCU  to  R-Gator 

1 

0.3  m 

321  m 

Yes 

692  m 

5,1,3  Discussion 

Generally,  the  ad  hoc  communications  system  worked  better  than  was  anticipated  and  much 
better  than  the  previous  generation  “black  box”  ad  hoc  nodes.  Not  only  were  they  packaged  in  a 
significantly  smaller  form  factor,  but  the  software  appeared  more  robust,  working  every  time  it 
was  powered  on. 

The  first  noteworthy  result  of  these  tests  was  the  distance  at  which  we  were  able  to  control  the 
robots.  The  old  “black  box”  version  of  ad  hoc  nodes  allowed  operation  of  a  robotic  platform  at 
distances  rarely  greater  than  100  m.  With  the  new  system,  we  were  consistently  obtaining  2  to  4 
times  greater  distance  from  the  OCU  to  a  robot — a  significant  improvement.  In  all  cases,  the 
video  was  viewed  in  CollectControl  at  a  rate  greater  than  10  frames  per  second  until  the  robots 
became  un-drivable,  at  which  point,  the  frame  rate  dropped  significantly. 

The  most  difficult  problem  we  had  was  with  the  video  becoming  bursty  at  lower  frame  rates  (less 
than  10  frames/second)  as  the  robot  to  OCU  distance  increased.  The  operator  observed  the  video 
smoothly  streaming,  when  a  slight  pause  where  the  video  seemed  to  stop,  followed  by  a  large 
number  of  old  video  frames  being  displayed  rapidly.  Many  times,  the  robot  was  correctly 
executing  the  commands  sent  by  the  operator,  but  the  video  displayed  on  the  OCU  did  not 
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correctly  reflect  the  robot  executing  the  eommands.  On  some  occasions,  both  the  control 
commands  on  the  robot  side  and  the  video  on  the  OCU  side  seemed  to  queue  up  and  then  burst 
out.  The  effect  was  the  robot  briefly  driving  itself  after  the  operator  had  stopped  moving  the 
joystick.  This  is  an  important  safety  issue  that  needs  to  be  studied  further.  Preliminary 
discussions  led  us  to  suspect  the  VPN  as  the  culprit.  However,  when  the  VPN  was  removed,  we 
observed  the  same  behavior.  Additional  research  needs  to  be  performed  in  order  to  isolate  the 
cause  of  this  problem. 

CollectControl  had  two  further  issues.  The  first  is  the  issue  of  a  platform  “commandeering” 
driving  control  from  the  operator.  This  is  a  known  issue  where  CollectControl  de-selecting  the 
“driving”  button  while  an  operator  is  controlling  a  robot  at  seemingly  random  intervals,  causing 
the  robot  to  stop  moving.  This  is  obviously  an  issue  that  needs  to  be  resolved,  sinee  losing 
control  of  a  robot  when  no  other  issues  are  at  play  (i.e.,  eommunieations  problems)  is 
unacceptable.  The  seeond  issue  is  that  CollectControl  de-selects  the  “driving”  button  when  the 
ad  hoe  network  experienees  a  slight  drop-out.  This  is  teohnieally  the  correct  functionality. 
However,  the  ad  hoe  network  infrequently  experiences  drop-outs  that  oeeur  momentarily  for  no 
apparent  reason,  and  it  regains  a  strong  conneetion  immediately  afterward.  Further  investigation 
is  needed  to  find  a  solution  that  prevents  ColleetControl  from  losing  control  during  short 
interruptions  in  network  eonneetivity. 

As  mentioned  before,  the  VPN  software  on  the  ad  hoe  nodes  was  originally  targeted  as  a  possible 
cause  of  the  bursty  video  performance.  While  the  removal  of  the  VPN  software  was  found  not  to 
be  the  eause  of  the  problematie  video  performance,  it  did  have  an  effect  on  the  network. 
Removing  the  VPN  software  redueed  reconnect  time,  following  one  of  the  nodes  being  powered 
off,  from  approximately  3  to  4  minutes  to  approximately  30  seconds.  The  engineers  in  CI-CN 
will  be  investigating  a  permanent  solution  to  reduce  the  reeonnect  time,  with  or  without  the  VPN 
software  running. 

The  tests  showed  us  the  importance  of  antenna  configuration  in  communicating  with  the  robots. 
On  the  drop-off  ad  hoc  nodes,  we  notieed  a  substantial  improvement  in  range  just  by  moving  the 
node  from  the  ground  to  on  top  of  an  upright  cinder  bloek,  a  height  increase  of  only  about 
0.45  m.  Replacing  the  stoek  antennas  on  the  drop-off  nodes  with  longer  antennas  with  a  higher 
gain  (and  more  flexibility  for  praetical  reasons)  eould  yield  better  performance.  Similarly,  the 
R-Gator  has  two  diversity  antennas  positioned  more  than  1.8  m  off  the  ground.  As  the  tests 
showed,  with  eommunication  payloads  operating  identical  software,  the  range  of  the  R-Gators 
was  greatly  increased  over  PackBot  performance.  This  replieated  the  results  obtained  by  the 
CI-CN  when  diversity  antennas  were  used  in  their  own  ad  hoe  network  tests  before  the  nodes 
were  delivered.  The  stock  internal  PackBot  communications  also  use  a  two-antenna  diversity 
configuration,  which  was  disabled  for  these  tests.  It  would  be  worthwhile  to  investigate  the  use 
of  the  existing  PaekBot  antennas  with  our  payload  or  modifying  the  payload  to  also  use  the 
diverse  eonfiguration. 
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5.2  Informal  Robotic  Field  Test  (Adelphi  Laboratory  Center) 

This  was  an  informal  test  performed  quickly  to  determine  if  a  recently  constructed  ad  hoc 
communications  payload  for  a  PackBot  was  operational.  It  was  performed  at  the  ALC  on 
25  May  2006  on  a  dead-end  road  leading  to  the  back  gate  of  the  post.  The  road  is  paved  with  a 
gentle  downhill  slope  and  a  “dog-leg”  to  the  right.  There  is  heavy  forest  cover  on  either  side  of 
the  road. 

5.2.1  Objectives 

Since  we  had  some  extra  time  following  the  initial  operational  check  of  the  payload,  we  decided 
to  also  test  the  operation  of  the  ad  hoc  network  in  a  multi-hop  configuration  in  a  slightly  different 
manner  than  our  multi-hop  test  at  Fort  Dix.  In  addition,  we  wanted  to  attempt  an  NLOS  test,  and 
the  inclusion  of  multiple  hops  through  ad  hoc  drop-off  nodes  allowed  us  to  test  the  network 
performance  as  the  road  made  a  near  90-degree  right-hand  turn  and  the  robot  moved  out  of  the 
line  of  sight. 

Here,  we  chose  to  place  the  drop-off  nodes  at  about  75%  of  the  maximum  one-hop  distance  for 
each  hop.  That  is,  we  planned  to  drive  the  PackBot  until  network  failure  and  then  placed  the 
next  ad  hoc  node  at  roughly  75%  of  that  distance.  This  was  repeated  for  each  hop  until  we  ran 
out  of  drop-off  nodes  and/or  the  network  failed.  Each  hop  was  one  of  the  following:  OCU  to 
robot,  ad  hoc  node  to  ad  hoc  node,  and  ad  hoc  node  to  robot.  For  this  test,  the  VPN  was  turned 
off  for  all  ad  hoc  nodes. 

5.2.2  Results 

The  network  successfully  routed  control  and  video  to  the  OCU  at  a  modest  frame  rate  of  7 
frames  per  second  and  resolution  of  320x240  through  two  drop-off  nodes.  The  total  distance 
traversed  was  483  m.  The  hop  from  the  second  drop-off  node  to  the  robot  was  around  the 
90-degree  bend  in  the  road,  creating  an  NLOS  situation  between  the  robot  and  the  OCU. 

5.2.3  Discussion 

This  was  an  informal  test  to  ensure  the  payload  was  working.  It  is  being  included  in  this 
document  solely  for  the  sake  of  complete  disclosure. 

The  network  operated  as  anticipated.  However,  we  noticed  one  issue  involving  network  routing 
latency.  When  the  robot  reached  the  “end”  of  the  network,  we  placed  an  ad  hoc  drop-off  node  at 
approximately  75%  of  that  distance,  as  described.  Leaving  the  robot  where  it  failed,  one  would 
expect  that  the  robot  would  regain  connectivity  following  the  power-up  of  the  newly  placed 
drop-off  node.  However,  it  tended  to  take  2  to  3  minutes  for  the  network  to  discover  that  it  could 
route  through  this  new  ad  hoc  node.  Thus,  there  was  a  noticeable  delay  after  the  drop-off  node 
was  powered  on  before  video  and  control  of  the  robot  were  regained  by  the  OCU.  This  is 
currently  being  investigated  by  CI-CN  and  will  be  re-evaluated  further  in  the  next  formal  round 
of  testing. 
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5,3  Formal  Robotic  Field  Test  (Adelphi  Laboratory  Center) 

Before  to  leaving  for  Fort  Dix  for  the  formal  UGV  evaluation,  we  wanted  to  do  additional 
performanee  testing  on  the  robotic  control  network  in  different  configurations,  as  well  as  fully 
test  the  PackBot  payloads  with  their  new  antennas,  added  per  the  results  of  a  previous  test  (initial 
robotic  field  test)^^.  The  tests  were  performed  at  ALC  on  1  June  2006  in  the  parking  lot  next  to 
and  on  the  roads  surrounding  the  Harry  Diamond  buildings,  as  well  as  in  a  wooded  area  between 
CISD’s  tents  and  the  path  on  the  western  edge  of  the  installation. 

5.3.1  Objectives 

The  goal  of  these  evaluations  was  to  do  more  rigorous  testing  on  the  robot-OCU  pair  to 
determine  how  the  ad  hoc  network  responded  to  non-standard  configurations  that  had  not  yet 
been  evaluated.  The  first  objective  was  to  determine  the  distance  over  which  the  ad  hoc 
communications  system  could  acceptably  operate  a  robotic  asset  using  multiple  hops  through  ad 
hoc  drop-off  nodes.  Next,  we  determined  the  performance  of  the  ad  hoc  network  in  NLOS 
applications  using  multiple  ad  hoc  drop-off  nodes.  This  included  determining  the  feasibility  and 
performance  of  the  ad  hoc  network  in  a  “mesh”  configuration  (i.e.,  blanketing  a  large  area  with 
multiple  drop-off  nodes).  We  also  hoped  to  determine  the  performance  of  the  ad  hoc  network 
over  multiple  hops  when  a  robotic  platform  (PackBot,  R-Gator)  rather  than  an  ad  hoc  drop-off 
node  acted  as  an  ad  hoc  relay  node.  Finally,  we  wanted  to  determine  the  performance  of  the  ad 
hoc  network  in  heavily  wooded  environments.  These  tests  were  performed  with  the  VPN  turned 
off  because  of  configuration  limitations. 

Because  this  evaluation  was  in  preparation  for  the  formal  UGV  evaluation  taking  place  at  Fort 
Dix,  we  hoped  to  mimic  some  of  the  evaluations  that  the  C4ISR  OTM  evaluators  would  be 
performing  on  our  robots,  such  as  target  detection  distance  and  target  classification^"^. 

5.3.2  Results 

In  performing  the  NLOS  test,  we  attempted  to  drive  a  PackBot  all  the  way  around  the  Harry 
Diamond  building  complex  at  ALC.  Ad  hoc  drop-off  nodes  were  placed  on  curbs  at  the  four 
comers  of  the  complex.  When  possible,  they  were  placed  on  something  that  raised  their  heights 
by  a  small  amount  (less  than  3  feet).  The  OCU  was  situated  on  a  small  cart  on  the  sidewalk 
adjacent  to  the  east  side  of  the  complex.  The  PackBot  was  driven  in  a  counter-clockwise 
direction  around  the  buildings.  Connection  was  not  established  between  all  the  drop-off  nodes  at 
the  onset  of  the  test.  The  PackBot  was  successfully  driven  down  the  front  side  of  the  building  to 
the  second  closest  drop-off  node.  However,  that  drop-off  node  could  not  make  a  connection  with 
the  next  drop-off  node.  Our  hope  was  that  the  PackBot  would  act  as  a  relay  between  the  two 
nodes  as  it  moved  between  them.  However,  because  of  the  elevation  change  between  the  two 

1  ^ 

Although  the  PackBot  tested  in  the  initial  robotic  field  test  had  the  new  antenna,  the  remaining  PackBot  communications 
payloads  still  had  a  different,  rigid  antenna  installed.  This  test  confirmed  operation  of  the  antennas  added  to  the  remaining 
PackBots. 

'"^Jennings,  R.,  “UGV  Evaluation”  Mitre  Corp. 
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nodes  on  the  far  side  of  the  building,  eommunieations  failed.  The  PaekBot  reaehed  just  over  half 
way  around  the  building  eomplex.  Attempts  were  made  during  the  test  to  increase  the  height  of 
the  drop-off  nodes  suffering  from  lack  of  connectivity  in  hopes  of  creating  a  network  connection. 
In  certain  cases,  a  link  was  created  as  a  result  of  this  but  would  only  increase  the  controllable 
distance  of  the  robot  for  a  few  feet  before  the  link  was  broken  again.  Several  changes  were  made 
in  the  ad  hoc  node  software  during  the  experiment  in  attempts  to  mitigate  these  issues.  These 
included  increasing  the  time  tolerance  in  an  effort  to  increase  the  distance  at  which  the  robot  was 
able  to  be  controlled  and  to  decrease  the  beacon  time.  Neither  of  these  changes  resulted  in 
substantial  improvements  in  connectivity  or  performance. 

For  the  mesh  connectivity  test,  ad  hoc  drop-off  nodes  were  placed  at  the  four  comers  of  the  main 
parking  lot  adjacent  to  building  202  at  ALC.  The  OCU  was  kept  in  the  same  location  on  the  east 
side  of  the  building.  We  used  the  CI-CN  ad  hoc  connectivity  visualization  software  to  visualize 
connections  and  their  strength  between  all  ad  hoc  nodes.  This  diagnostic  software  indicated  that 
all  the  ad  hoc  nodes  had  connections  to  every  other  ad  hoc  node  immediately  after  all  the  devices 
were  powered  up.  The  robot  was  driven  across  the  parking  lot  with  no  loss  of  connection  or 
reduction  in  video  quality. 

Evaluating  the  robots  in  the  wooded  area  proved  to  be  pertinent  to  the  environment  the  robots 
would  be  operating  in  at  Fort  Dix.  We  had  not  been  able  to  communicate,  using  the  old  ad  hoc 
communications  systems,  through  a  heavily  wooded  area  approximately  150  m  in  extent.  This 
test  was  to  stand  at  a  clearing  on  one  side  of  the  woods  with  the  OCU  and  attempt  to  drive  the 
PaekBot  through  this  150-m  woods  with  no  ad  hoc  drop-off  nodes.  If  the  robot  could  not  be 
controlled  the  whole  distance,  an  ad  hoc  drop-off  node  would  be  placed  part  way. 

While  performing  the  test  in  a  heavily  wooded  area,  we  drove  the  PaekBot  into  a  large  downed 
tree  branch  which  punctured  the  ad  hoc  payload.  Upon  the  PaekBot’ s  encounter  with  the  branch, 
the  power  to  the  payload  was  intermpted.  Since  we  were  unable  to  regain  communications  with 
the  robot,  testing  was  suspended  for  the  day,  since  our  only  ad  hoc  payload  had  been  damaged 
(the  others  were  on  site  at  Fort  Dix).  We  learned  that  the  branch  had  merely  knocked  loose  one 
of  the  power  wires  in  the  payload,  which  suffered  no  significant  internal  damage. 

Thus,  not  all  of  the  objectives  were  achieved,  for  two  reasons.  First,  the  recently  constmcted  ad 
hoc  drop-off  nodes  requiring  testing  were  not  completed  in  time,  mainly  because  of  procurement 
delays.  Secondly,  the  ad  hoc  payload  on  our  test  PaekBot  was  rendered  temporarily  inoperable 
by  the  aforementioned  tree  branch  while  we  were  performing  the  wooded  area  testing. 

5,3.3  Discussion 

There  are  a  number  of  issues  that  we  believe  to  have  contributed  to  the  failure  of  the  NFOS  test. 
Most  notably,  the  elevation  changes  around  the  building  affected  the  performance  of  the 
network.  Because  the  PaekBot  and  the  ad  hoc  drop-off  nodes  operate  very  low  to  the  ground, 
many  times  there  is  no  line  of  sight  connection  between  nodes  even  over  very  small  rises. 
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Although  this  does  not  often  sever  the  link  created,  it  can  significantly  decrease  the  signal 
strength,  causing  a  drop  in  available  video  frame  rate,  which  greatly  affects  the  user’s  ability  to 
drive  a  robot. 

Through  monitoring  the  network  visualization  software,  we  observed  some  “oscillation”  between 
which  nodes  the  robot  would  route  through  when  in  view  of  two  nodes.  The  delay  in  packet 
forwarding  as  routes  switched  between  nodes  caused  a  noticeable  lag  in  the  video  display  in 
CollectControl,  making  it  difficult  to  control  the  robot.  We  hypothesized  that  this  was  caused 
because  the  VPN  was  turned  off.  However,  we  were  not  able  to  verify  that  claim  during  this  test. 

The  initial  mesh  connectivity  test  was  inconclusive.  In  short,  the  network  performed  too  well. 
We  had  hoped  to  see  the  robot  moving  across  the  parking  lot  and  connecting  to  the  closest 
node(s)  as  appropriate,  but  instead,  we  saw  the  robot  connect  to  all  the  nodes  at  once.  We  clearly 
need  to  perform  this  test  in  a  larger  area  or  perhaps  in  more  diverse  terrain  (wooded,  hilly)  to  be 
able  to  observe  varying  behavior. 

5,4  Preliminary  UGV  Evaluation  (Fort  Dix,  New  Jersey) 

Because  the  C4ISR  OTM  program  managers  wrote  their  UGV  evaluation,  based  on  a  less- 
capable  UGV  platform  that  was  used  in  the  experiment  the  previous  year,  they  thought  it 
advantageous  for  us  show  them  some  capabilities  of  the  robotic  systems  and  the  ad  hoc  network 
before  the  formal  UGV  evaluation.  We  used  this  as  an  opportunity  to  perform  more  tests  and  to 
observe  the  behavior  of  the  network  in  the  field.  The  evaluation  was  performed  on  Tactical 
Range  9D  at  Fort  Dix  on  6  June  2006  under  overcast  conditions. 

5.4.1  Objectives 

The  test  we  devised  was  to  drive  on  the  dirt  trails  in  the  heavily  wooded  area  from  a  clearing. 

The  robot  was  driven  until  control  was  lost,  then  an  ad  hoc  drop-off  node  was  emplaced,  control 
regained,  and  the  operator  continued  to  drive  the  robot  until  the  procedure  stopped  working. 
Given  the  environment,  this  allowed  us  to  simultaneously  evaluate  the  network  performance  in 
NLOS,  wooded,  hilly,  and  non-urban  environments. 

5.4.2  Results 

We  drove  the  PackBot  down  a  canyon-like  trail  that  sloped  away  from  the  OCU  until  we  lost 
control.  We  then  placed  ad  hoc  drop-off  nodes  in  line  of  sight  from  the  OCU  to  the  drop-off  to 
the  robot  at  the  highest  location  we  could  using  the  terrain.  The  original  plan  was  to  use  one  or 
two  drop-off  nodes  to  get  through  the  trail  to  a  clearing  where  a  target  HWMMV  was  located, 
and  take  a  picture  of  it  in  CollectControl.  We  accomplished  that  easily  using  only  one  drop-off 
node,  so  we  continued  adding  nodes  to  the  network  and  drove  the  PackBot  farther  away  from  the 
OCU.  After  adding  a  second  node,  we  were  able  to  drive  it  so  far  that  it  took  us  nearly 
10  minutes  to  locate  the  robot,  as  when  driving  the  operator  was  simply  driving  toward  open, 
sandy  areas,  with  no  concern  for  where  the  robot  was  on  the  map.  It  is  very  easy  to  get 
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disorientated  when  tele-operating  the  robot  in  this  manner.  Although  the  robot  appeared  in  its 
eorreet  loeation  on  the  mapping  system,  limitations  in  map  resolution  and  the  hilly,  wooded 
terrain  made  it  diffleult  to  loeate.  After  finding  the  robot,  we  were  able  to  drive  through  3  and  4 
nodes  before  we  deeided  to  stop  when  eontrol  was  beeoming  questionable.  Control  beeame 
more  bursty  with  the  video  freezing  and  suddenly  displaying  all  frames  as  eontrol  was  routed 
through  more  network  hops  and  the  distanee  between  nodes  inereased.  No  formal  distanees  were 
measured  in  this  evaluation,  but  they  were  eomparable  to  those  obtained  in  the  first  Fort  Dix 
field  test  at  the  beginning  of  May. 

5,4,3  Discussion 

This  evaluation  was  eonsidered  a  sueeess,  as  it  demonstrated  to  the  program  managers  that  our 
robotie  system  was  more  than  eapable  of  providing  a  wide  range  of  possible  operating  seenarios. 

As  seen  in  previous  tests,  there  were  times  when  the  network  was  approaehing  its  maximum 
working  distanee  and  eonneetivity  temporarily  dropped  out,  eausing  ColleetControl  to  release 
eontrol  of  the  robot,  even  though  it  immediately  had  a  strong  frame  rate  following  the  gliteh.  As 
noted  elsewhere,  this  behavior  is  the  result  of  a  eonseienee  deeision  made  for  safety  eoneerns. 

We  also  observed  that  video  from  the  PaekBot  was  limited  to  frame  rates  of  three  to  four  frames 
per  seeond  at  very  elose  distanees  to  the  OCU  (less  than  3  m).  This  is  the  result  of  deliberate 
tuning  of  the  ad  hoe  routers  performed  during  this  evaluation,  allowing  for  greater  eontrol 
distanee  at  the  expense  of  throughput  at  short  ranges.  In  most  operating  seenarios,  this  is  not  an 
issue. 


5,5  UGV  Evaluation  (Fort  Dix,  New  Jersey) 

Researehers  from  HRED  were  present  at  the  evaluation  to  gather  human  faetors  data  on  the 
human  operator-PaekBot  system  interaetion.  We  antieipated  an  exeellent  outeome  of  this  test 
sinee  the  PaekBot  was  designed  to  operate  in  urban  environments  rather  than  the  heavily  wooded 
environments  it  had  eneountered  thus  far.  The  evaluation  was  performed  at  the  Time  Square 
military  operations  in  urban  terrain  (MOUT)  site  at  Fort  Dix  on  8  June  2006.  This  MOUT  site 
eonsisted  of  a  number  of  dirt  streets  lined  with  buildings  made  of  large,  metal  shipping 
eontainers.  The  buildings  eontained  various  furnishings,  sueh  as  tables,  ehairs,  and  mannequins 
representing  eivilians.  Many  buildings  were  two  stories  and  had  interior  or  exterior  staireases. 
Also  present  at  the  site  were  numerous  oars  parked  on  the  sides  of  the  roads.  One  road  oontinued 
past  the  MOUT  site,  as  if  heading  to  the  suburbs  and  provided  +0.25  mile  of  straight,  fiat  road. 

5,5,1  Objectives 

The  primary  objeotive  of  the  evaluation  was  to  demonstrate  the  oapabilities  of  our  robotie  system 
in  an  urban  environment.  This  inoluded  how  well  the  ad  hoe  network  funotioned  in  an 
environment  full  of  refleotive  metal  surfaoes  and  obstruoted  views.  Although  unrelated  to 
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network  performance,  we  also  hoped  to  show  the  urban  environment  capabilities  of  the  PackBot, 
such  as  stair  climbing  and  operation  in  the  dark. 

5,5.2  Results 

The  first  test  we  ran  was  a  straight  line  distance  test.  Although  similar  tests  had  been  performed 
on  uneven  terrain,  this  test  offered  a  very  fiat,  straight  stretch  of  dirt  road  on  which  to  test.  In 
addition  to  taking  advantage  of  the  road,  we  thought  it  would  be  interesting  to  see  if  the  alley  at 
the  beginning  of  the  road,  through  which  the  robot  would  pass,  would  challenge  the  network. 
Standing  at  the  entrance  to  the  MOUT  site  at  the  beginning  of  the  dirt  road,  we  were  able  to 
operate  the  PackBot  and  R-Gator  as  far  as  386  m  and  402  m,  respectively.  These  distances  were 
actually  better  than  our  initial  straight  line  testing  performed  in  June.  Although  we  lost  the 
ability  to  control  the  PackBot  at  that  distance,  the  R-Gator  still  had  a  good  connection  but  was  at 
the  end  of  the  road. 

The  next  test  was  evaluating  the  NLOS  performance  in  the  urban  environment.  The  goal  was  to 
drive  the  robotic  platforms  all  the  way  around  the  triangular  city  block  at  the  MOUT  site.  We 
hypothesized  that  on  the  far  side  of  the  block,  the  significant  amount  of  metal  buildings  would 
most  likely  severely  affect  the  network.  With  the  operator  inside  one  of  the  metal  buildings,  the 
connection  was  lost  and  drop-off  nodes  were  placed  at  the  corners  of  the  block.  This  allowed 
continued  successful  driving  of  the  PackBot,  with  the  OCU  maintaining  a  reasonable  frame  rate 
and  good  control  of  the  robot  the  rest  of  the  way  around  the  block.  With  the  operator  standing  at 
the  entrance  to  the  MOUT  site,  the  PackBot  was  able  to  be  driven  all  the  way  around  the  block 
without  the  use  of  the  drop-off  nodes.  The  R-Gator  was  able  to  drive  half  way  around  the  block 
during  its  test,  going  just  out  of  sight  around  the  corner.  However,  at  that  point,  a  mechanical 
failure  on  the  R-Gator  resulted  in  it  having  to  be  withdrawn  from  the  test. 

The  final  test  required  an  operator  to  clear  a  two-story  building  from  a  concealed  location  in  a 
building  across  that  street.  Of  interest  was  whether  a  tele-operated  robotic  search  could  be 
completed  with  an  acceptable  level  of  thoroughness  and  in  a  timely  manner.  The  operator  sat  in 
a  chair  away  from  windows  on  the  ground  level  of  one  of  the  buildings  along  a  road  in  the 
MOUT  site.  The  robot  was  placed  at  the  entrance  to  a  different  building  across  the  street.  Using 
only  the  OCU,  the  operator  then  attempted  to  clear  the  building,  which  involved  checking  all 
rooms  on  both  levels  for  civilians  (mannequins)  and,  if  detected,  taking  imagery  of  the  civilians. 
This  would  test  the  ad  hoc  communication  network’s  ability  to  operate  between  two  metal 
buildings  in  an  urban  environment  and  the  effectiveness  of  using  a  UGV  for  this  type  of 
reconnaissance.  The  test  was  performed  four  times  in  buildings  of  various  configurations.  The 
system  demonstrated  good  utility  in  this  exercise,  clearing  a  two-story  building,  including  going 
up  and  down  stairs  in  the  dark,  in  10  minutes.  Overall,  the  operator  was  able  to  correctly  identify 
88%  of  the  civilians  in  a  building,  with  the  PackBot  having  some  trouble  finding  targets  that 
were  not  easily  apparent  from  its  low  vantage  point.  However,  had  the  operator  taken  more  time 
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in  each  room  to  maneuver  the  PackBot  camera  arm,  the  probability  of  detection  may  have 
improved. 


Figure  8.  PackBot  operating  at  MOUT  site. 

5,5.3  Discussion 

The  main  issue  we  expected  to  see  in  this  evaluation  was  network  degradation  caused  by 
buildings,  since  metal  tends  to  reflect  wireless  signals  in  unpredictable  ways,  causing  severe 
multi-path  interference  issues.  However,  these  effects  were  largely  unnoticed.  In  the  straight 
line  distance  test,  we  observed  much  better  distances  than  we  did  in  an  open  field.  This  may 
have  been  attributable  to  the  ground  being  flatter  than  at  the  initial  test  site,  but  the  fact  remains 
that  the  buildings  did  not  contribute  negatively  to  the  performance  of  the  network.  Similarly, 
when  attempting  the  building-clearing  behavior,  we  expected  the  network  to  become 
questionable  as  soon  as  the  robot  entered  its  objective  building.  Again,  however,  the  network 
performed  well,  with  strong  connectivity  throughout  the  building.  The  only  time  anticipated 
network  problems  actually  occurred  was  when  we  drove  the  robot  around  the  block.  We 
expected  the  connection  to  drop  on  the  far  side  of  the  block,  since  there  was  a  large  amount  of 
structure  between  the  OCU  and  robot.  As  expected,  the  connection  dropped  when  the  operator 
was  located  indoors.  However,  the  network  regained  its  previous  performance  when  the  ad  hoc 
drop-off  nodes  were  placed  in  the  intersections  on  the  comers  of  the  block  and  never  lost  a  level 
of  performance  when  the  operator  was  outdoors.  We  had  expected  to  see  more  interference 
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issues  related  to  the  large  amount  of  sheet  metal  at  the  MOUT  site  but  were  encouraged  when 
that  did  not  occur. 

5,6  C4ISR  On-The-Move  Experiment  (Fort  Dix,  New  Jersey) 

All  this  testing  and  evaluation  was  in  preparation  for  three  weeks  (10  July  2006  to  28  July  2006) 
of  experimentation  to  be  performed  by  trained  United  States  National  Guard  Soldiers. 
Throughout  the  three-week  period,  varying  sets  of  technology  were  combined  and  given  to  the 
Soldiers  for  use  in  mock  operational  scenarios.  The  goal  was  to  determine  how  well  the  future 
technologies  might  improve  the  Soldier’s  SA,  at  dismounted  and  higher  echelons. 

The  actual  “experiment”  was  really  a  demonstration,  since  experimentation  with  the  systems  had 
already  taken  place.  No  changes  were  made  in  the  network  over  the  course  of  the  three  weeks, 
and  it  performed  as  we  had  anticipated.  In  fact,  the  biggest  problem  with  the  robotic  control 
system  had  nothing  to  do  with  the  technology  itself  but  in  getting  the  Soldiers  to  use  the 
technology.  There  was  some  frustration  among  CISD  folk  regarding  how  and  how  much  our 
equipment  was  used  by  the  Soldiers  in  the  field.  CISD  engineers  provided  adequate  training 
before  the  experiment  to  familiarize  the  Soldiers  with  the  capabilities  and  controls  of  the 
unmanned  systems.  However,  this  is  indicative  of  a  larger  Army  doctrine  issue  relating  to  the 
use  of  unmanned  systems,  not  issues  with  the  technology  itself. 

Two  technology  related  issues  did  present  themselves  during  the  experiment.  The  first  was  an 
issue  of  communicating  in  very  dense  forest  locations  on  a  few  occasions.  It  was  reported  to  us 
that  when  a  Soldier  was  attempting  to  drive  a  PackBot  from  a  prone  position  in  deep  wooded 
cover,  the  operational  range  was  reduced  to  approximately  9  m.  Although  there  are  possible 
physical  limitations  of  the  system  at  play  here,  with  the  antennas  on  the  OCU  and  PackBot  being 
very  close  to  the  ground  and  severely  obstructed  paths  limiting  connectivity,  the  result  was 
surprising.  This  poor  level  of  network  performance  had  not  been  exhibited  during  any  of  the 
previous  tests.  Because  of  experimental  design  constraints,  we  were  not  able  to  observe  or 
troubleshoot  this  issue  in  the  field  during  the  exercise  as  it  occurred. 

The  second  issue  was  specific  to  the  R-Gator.  CISD  added  a  high-powered  camera  to  the  R- 
Gator  platform,  a  DI-5000  made  by  Digital  Infrared  Imaging,  Inc.  When  the  DI-5000  was 
pointed  at  a  visually  complex  scene,  such  as  a  very  densely  wooded  environment  at  close  range, 
the  packets  that  the  Motion- JPEG  video  compression  scheme  created  were  very  large.  It  was 
observed  that  when  the  camera  was  pointed  toward  such  scenes,  the  ad  hoc  network  did  not 
forward  the  packets  at  a  resolution  of  320x240,  the  default  CollectControl  resolution.  This  was 
confirmed  when  a  lower  resolution  (160x120)  was  specified;  lower  quality  video  containing 
smaller  packets  streamed  over  the  ad  hoc  network.  As  a  workaround,  the  Motion- JPEG 
compression  level  for  the  DI-5000  was  increased.  This  resulted  in  smaller  video  packets  that  did 
not  cause  problems  on  the  ad  hoc  network;  however,  the  higher  compression  level  substantially 
decreased  the  quality  of  the  image.  Both  of  these  issues  will  be  further  examined  at  AEG. 
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6.  Conclusion  and  Future  Work 


As  a  whole,  ARL’s  involvement  in  the  C4ISR  OTM  experiment  was  a  suceess.  The  MANET 
and  robotic  platforms  performed  admirably  with  minimal  issues  throughout  the  summer,  often 
enduring  100  °F  and  high  humidity.  However,  as  noted,  there  are  three  issues  that  need  to  be 
further  investigated  (bursty  video,  the  large  packet  issue,  and  reduced  network  performance  in 
heavily  wooded  areas).  The  likely  candidates  in  the  bursty  video  issue  are  the  ad  hoc  routing 
protocol  and  CollectControl.  The  ad  hoc  software  will  be  examined  to  determine  if  it  is  queuing 
the  video  frames,  and  CollectControl  will  be  studied  to  possibly  include  an  algorithm  to  discard 
old  video  frames  so  they  are  not  displayed.  The  solution  to  this  issue  could  impact  the  resolution 
of  the  other  two.  There  is  a  test  plan  in  place  for  further  investigation  of  these  issues,  and  it  will 
be  conducted  as  time  and  manpower  allow. 

Work  will  continue  on  the  operation  and  evaluation  of  this  network  in  true  ad  hoc  fashion, 
without  the  VPN  activated.  Although  its  application  in  this  experiment  (as  an  end-to-end 
network  with  the  ability  to  use  any  drop-off  node)  had  its  advantages,  the  true  benefit  of  an  ad 
hoc  network  lies  in  its  ability  to  connect  a  large  group  of  mobile  nodes.  As  such,  provided  that 
higher  level  network  architecture  does  not  prevent  it,  the  network  will  be  implemented  as  a  true 
MANET. 

After  watching  Soldiers  use  the  ad  hoc  drop-off  nodes  in  a  field  environment,  we  observed  that 
they  often  had  difficulty  emplacing  the  nodes  in  locations  that  would  improve  network 
connection  and/or  performance.  It  could  be  beneficial  to  include  a  utility  for  visualizing  network 
strength  and  connectivity  on  the  OCEl,  aiding  the  Soldiers  in  intelligently  placing  the  nodes. 

Such  a  piece  of  software  exists  in  CI-CN,  but  it  does  not  easily  lend  itself  to  integration  into  an 
OCU-user  interface.  Further  investigation  into  how  best  represent  this  information  to  the  user 
will  occur  in  the  future. 

Ongoing  research  into  quality  of  service  and  intrusion  detection  for  MANETs  is  being  performed 
at  ARE.  It  is  hoped  that  these  research  areas  will  lead  to  more  secure  and  robust  ad  hoc  networks 
and  could  be  implemented  on  the  MANET  discussed  in  this  document. 

Finally,  as  the  robotic  platforms  that  are  controlled  in  an  ad  hoc  network  become  smaller  and 
more  constrained,  the  packaging  for  the  COTS  wireless  routers  running  the  ad  hoc  software  will 
need  to  be  examined.  Presently,  the  COTS  pieces  were  used  “as  is,”  being  strapped  to  the  back 
of  the  OCU  or  inserted  into  large  payload  containers  on  the  mobile  platform.  As  the  platforms 
shrink,  so  does  their  ability  to  carry  large,  modular  payloads.  A  highly  integrated  approach  to 
developing  the  communications  hardware  may  need  to  be  investigated. 
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